Conventionally, connecting multiple communications apparatuses, each having its own communications function, via a network for communicating, and building various systems are performed. As an example, there is a so-called electronic-commerce system such that an order for a product is transmitted from a computer such as a PC (Personal Computer) that functions as a client apparatus and accepts the order in a server apparatus that communicates with the client apparatus via the Internet. Moreover, a system is being proposed such that various electronic apparatuses are provided with a function of a client apparatus or a server apparatus so as to be connected via an network, and are remotely controlled by mutual communications.
In building such systems, it is important to confirm when communicating whether a communications counterpart is appropriate, or whether information being transmitted has not been tampered with. Moreover, especially in the Internet, as often information goes through computers that are unrelated before reaching the communications counterpart, when transmitting secret information, there is also a demand for making sure that the contents are not viewed secretly. Then, a protocol such as SSL (Secure Sockets Layer), for example, as a communications protocol to respond to such demand is being developed and widely used. Using this protocol to communicate combines public-key encrypting methods and common-key encrypting methods for authenticating the communications counterpart as well as preventing tampering and tapping by encrypting information. Moreover, even at the communications-counterpart side, a communications-originating apparatus that requests for communications is authenticated.
As technologies related to authentication using such SSL and public-key encrypting, there are those described in Patent Documents 1 and 2:
Patent Document 1                JP2002-353959A        
Patent Document 2                JP2002-251492A        
Now, a communications procedure for mutually authenticating according to this SSL is described focusing on the authentication process portion. FIG. 34 is a diagram illustrating a flow of a process of executing in each apparatus when communications apparatuses A and B mutually authenticate according to the SSL, along with information used for the process.
As illustrated in FIG. 34, when mutually authenticating according to the SSL, there is a need to first have a root-key certificate, a private key, and a public-key certificate stored in both of the communications apparatuses. This private key is a private key issued to each apparatus by a CA (Certificate Authority), while the public-key certificate is one such that the public key corresponding to the private key is appended with a digital signature by the CA so as to be set as a digital certificate. Moreover, the root-key certificate is one such that a root key corresponding to a root-private key used in the digital signature is appended with a digital signature so as to be set as a digital certificate.
FIGS. 34A and 34B illustrate these relationships.
As illustrated in FIG. 35A, a public key A is configured from a main body of the key for decrypting text encrypted using a private key A, and bibliographical information which includes such information as issuer (CA) of the public key and validity. Then, in order to indicate that the main body of the key and the bibliographical information are not tampered with, a hash value obtained by hashing the public key A is encrypted using a root-private key so as to be applied to a client common key as a digital signature. Moreover, at that time, information identifying the root-private key used in the digital signature is added as signature-key information to the bibliographical information of the public key A. Then, the public-key certificate having this digital signature applied is a common-key certificate A.
When using this common-key certificate A for authenticating, the digital signature contained therein is decrypted using a main body of a root key being a public key corresponding to the root-private key. It is understood when this decrypting is performed successfully that the digital signature is certainly applied by the CA. Moreover, it is understood when the hash value obtained by hashing the public key A portion and a hash value obtained by decrypting matches that the key itself is also neither damaged nor tampered with. Furthermore, it is understood when it is possible to successfully decrypt the received data using this public key A that the data is transmitted from the owner of the private key A.
Now, while it is necessary to store in advance a root key for performing authentication, as illustrated in FIG. 34B, this root key is stored as a root-key certificate having applied a digital signature by the CA. This root-key certificate is in a self-signature format enabled to decrypt the digital signature with a public key contained therein. Then, when using the root key, the main body of the key contained in the root-key certificate is used to decrypt the digital signature so as to compare with the hash value obtained by hashing the root key. When there is a match, it is possible to confirm that the root key is not corrupted, for instance.
Now the flowcharts in FIG. 34 are described. It is noted that in this diagram, an arrow between the two flow charts represents transferring of data such that the transmitting side performs a transferring process at a step from which the arrow originates, while the receiving side once the information is received performs a process of a step to which the arrow points. Moreover, when a process of each of the steps is not successfully completed, at that time a response of having failed authentication is returned so as to suspend the process. The same holds when a response of having failed authentication is received from the counterpart, or upon time-out of the process.
Now, with a communications apparatus A requesting for communications with a communications apparatus B, when performing this request, the CPU of the communications apparatus A executing a required control program starts a process of the flowchart illustrated on the left-hand side of FIG. 34. Then, in step S11, a request for connection is transmitted to the communications apparatus B.
On the other hand, the CPU of the communications apparatus B once receiving this request for connection executing a required control program starts a process of the flowchart illustrated on the right-hand side of FIG. 34. Then, in step S21 a first random number is generated for encrypting using a private key B. Then, in step S22, the encrypted first random number and a public-key certificate B are transmitted to the communications apparatus A.
At the communications apparatus A side, when receiving this, in step S12 the validity of the public-key certificate B is confirmed using a root-key certificate.
Then once confirmed, in step S13 the first random number is decrypted using a public key B contained in the received public-key certificate B. When the decrypting here is successful, confirming that the first random number is certainly received from a subject to which the public-key certificate is issued is enabled. Then, when the confirming as described above is successful, information indicating success of authentication is transmitted to the communications apparatus B.
Moreover, at the communications apparatus B side, upon receiving this information, in step S23, transmission of a public-key certificate for authentication is requested from (request sent to) the communications apparatus A.
Then, at the communications apparatus A, based on the above request for transmission, in step S14, a second random number and a common-key seed are generated. A common-key seed may be generated based on data transacted in previous communications, for example. Then, in step S15 the second random number is encrypted using a private key A, the common-key seed is encrypted using the public key B, and in step S16 these are transmitted with a public-key certificate A to the communications apparatus B side. Encrypting the common-key seed is performed for the purpose of making sure that the random number is not known to apparatuses other than the communications counterpart.
Then, in the next step S17, a common key for use in encrypting subsequent communications is generated from the common-key seed generated in step S14.
At the communications apparatus B side, when receiving this, in step S24 the validity of the public-key certificate A is confirmed using the root-key certificate. Then once confirmed, in step S25, the second random number is decrypted using a public key A contained in the public-key certificate A received. When the decrypting here is successful, confirming that the second random number is certainly received from a subject to which the public-key certificate A is issued is enabled.
Subsequently, in step S26 the common-key seed is decrypted using a private key B. It can be said that, in the process thus far, the first through the third common-key seed common to the communications apparatus A side and the communications apparatus B side are shared. Then, at least the common-key seed does not become known to apparatuses other than the communications apparatus A having generated the number and the communications apparatus B having the private key B. Once the process described thus far succeeds, also at the communications apparatus B side in step S27 a common key for use in encrypting subsequent communications is generated from the common-key seed obtained by decrypting.
Then, once the process of step S17 at the communications apparatus A side and the process of step S27 at the communications apparatus B side are terminated, success of authentication and encrypting method for use in subsequent communications are mutually confirmed for terminating the process regarding authentication assuming that the generated common key is used to conduct the subsequent communications using the encrypting method confirmed as described above. It is noted that the confirming as described above includes a response from the communications apparatus B that authentication has succeeded. The process as described above enables mutually establishing communications so as to subsequently use the common key generated in step S17 or S27 and to encrypt data according to the common-key encrypting method for conducting communications.
Performing such process as described above enables securely sharing a common key upon the communications apparatus A and communications apparatus B mutually authenticating their counterparts, and establishing a path for communicating securely.
It is noted that in the process as described above, it is not mandatory to encrypt the second random number with the private key A and to transmit the public-key certificate A to the communications apparatus B. In this way, the process of steps S23 and S24 at the communications apparatus B side is not required so that the process becomes as illustrated in FIG. 36. In this way, while it is not possible for the communications apparatus B to authenticate the communications apparatus A, this process is sufficient when it suffices for the communications apparatus A to only authenticate the communications apparatus B. Then in this case, it is necessary to have only the root-key certificate stored in the communications apparatus A so that neither the private key A nor the public-key certificate A are needed. Moreover, it is not necessary to have the root-key certificate stored in the communications apparatus B.
In the authentication process as described above, the authentication is performed such that, using the fact that the contents encrypted with a public key can only be decrypted at an apparatus having a corresponding private key, and, the contents encrypted with a private key can only be decrypted with a corresponding public key, a communications counterpart is described in a public-key certificate as its subject to which the certificate is issued (or a user of the apparatus is a user for which the public-key certificate describes as the subject to which the certificate is issued).
Moreover, it is understood that, assuming the integrity of privacy of the root-private key of the CA, the public-key certificate is authenticated by the CA such that (the provider of) the CA guarantees the accuracy of the contents described in the public-key certificate. However, the fact that the communications counterpart is certainly the same as the apparatus described in the public-key certificate can only be determined by relying on the guarantee of the CA having issued the public-key certificate. Therefore, the reliability of the CA becomes an important factor when maintaining the security of communications by authentication using public-key encrypting.
Then, in a case of trying to authenticate a communications counterpart using such a public-key certificate, for preventing such behavior as getting authenticated by disguising as another apparatus or using a counterfeit certificate to get authenticated, describing in the public-key certificate information identifying the apparatus being the subject of issuing or using the public-key certificate issued by a highly-reliable, trusted third party is effective.
However, even when trying to authenticate using such a public-key certificate, successful authenticating is not possible when the public-key certificate is corrupted or the validity has expired. More specifically, as the public-key certificate issued by a trusted third party has a short validity period of approximately 1 to 3 years, the validity may expire while the apparatus having stored the certificate is stored in a warehouse.
Then, in a case where the communications counterpart has stored only one type of public-key certificate, the communications counterpart can no longer be authenticated. Moreover, as it is not possible to establish a secure communications path with the communications counterpart, having the communications counterpart to securely store a new public-key certificate (and private key) causes the need to send these via a different route such as post.
However, when sending the new public-key certificate, etc., via the post, etc., setting the communications apparatus needs to be done manually. Therefore, this setting is difficult when updating by an operator is difficult due to the skill level of the user envisaged and the user environment, or it is not preferable to have the operator freely set a public-key certificate from the point of view of operating the apparatus.
The applicant of the present application has proposed a method of updating a public-key certificate and has made patent applications (i.e. Japanese Patent Application Nos. 2003-201638 and 2003-341329, etc., pending); the method, as a method of settling the problems as described above, is such that a communications apparatus is set to store a public-key certificate for normal use, as well as a common-key certificate to be stored as a common one for each apparatus without having to include information identifying the apparatus, and a public-key certificate having a validity period longer than the public-key certificate for normal use, that are to be used as a rescue certificate, so as to update a public-key certificate being corrupted or a public-key certificate for which the validity has expired.
In this method, in each communications apparatus, when authentication with the public-key certificate for normal use in the communications apparatus is no longer possible, an apparatus having a function of setting a certificate provides for using a rescue public-key certificate to authenticate the communications apparatus so that when this is successful a new public-key certificate, etc., for normal use is transmitted to the communications apparatus.
Therefore, according to such a method, even when the public-key certificate for normal use is made unavailable for use, securely obtaining a new public-key certificate, etc., from the apparatus having the function of setting a certificate so as to set the certificate, etc., is enabled, providing the ability to get reauthenticated using a public-key certificate for normal use.
Now, even when mutually authenticating using a public-key certificate, etc., such that the security is sufficiently maintained, it is possible that the security may become not sufficient due to such reasons as the strength of the cipher becoming insufficient due to progress in technologies. For instance, when a computationally-superior computer or a suitable algorithm is developed, if a public key having a short key-length is used, there will be risk that a private key is derived from the public key in a short time frame. Thus, in order to respond to such a situation, there is a demand for making it possible to respond by changing the key length of the public key.
Moreover, in order to describe many information items within the public-key certificate, there is a demand for changing the format of the public-key certificate.
Thus when changing the key length or the format of the public key, there arises a need for a CA to newly provide the public key. However, in this case, as the validity of the new digital certificate issued by the CA cannot be confirmed with a previous root key, it is not possible to authenticate. Therefore, for authentication, a public-key certificate, a private key, and a root-key certificate supporting a new key-length or format need to be transferred.
It is possible to apply a technology as described in the Non-Patent Document 1, for example, when having a newly produced apparatus store a certificate or a key in response to such a new key-length or algorithm. However, the Non-Patent Document 1 describes no method for delivering such certificate having the new key-length or format to an apparatus already shipped and being operated by a customer.
Non-Patent Document 1                “RSA Keon (Registered trademark) Factory—CA Solution”, (online), RSA Security Co., (searched Nov. 26, 2003), the Internet <URL: http://www.rsasecurity.com/japan/products/keon/keon_factory-ca.html>        
On the other hand, it is possible to transfer the public-key certificate, etc., supporting the new key-length and the format as described above with the method of using the rescue public-key certificate as described above. In other words, when an apparatus authenticating each apparatus stops authenticating using a public-key certificate before a change, the communications apparatus cannot get authenticated with the public-key certificate before the change. Then a method is possible such that, as a predetermined communications counterpart is requested authentication with a rescue public-key certificate, when the communications counterpart authenticates the communications apparatus with the rescue public-key certificate, a public-key certificate, etc., supporting a new key-length or format is delivered to the communications apparatus.
However, as the public-key certificate used for rescue is always enabled for authenticating using the certificate, it has a characteristic of not containing information identifying the apparatus or having a long validity period so as to be somewhat inferior relative to the public-key certificate for normal use from the security point of view. Moreover, as the communications path being maintained for using the rescue public-key certificate is strictly for use in an emergency, when it is known in advance that authentication cannot be made, there is a demand for making do with as little as possible.
Furthermore, when trying to deliver a new public-key certificate, etc., to a large number of communications apparatuses, immediately after authenticating using the public-key certificate before the change is stopped, a large number of accesses to the apparatus delivering the new public-key certificate, etc., for rescue ends up becoming concentrated. Therefore, there is a problem such that the apparatus for delivery may end up going down, making delivering of the new public-key certificate, etc., impossible.